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Remarks/ Arguments 

A. Claims in the Case 

Claims I, 3-24, 26-51, 53-73, 147, and 488 are pending. Claims 1, 3, 4, 19, 20, 24, 26, 
27, 42, 43, 51, 53, 54, 69, 70, 147, and 488 have been amended. Claims 2, 25, and 52 have been 
cancelled. 

B. Objection 

Claim 2 was objected to because the claim reads "...processing relationship value from 
an FSO transaction related data in the FSO computer system." Applicant has amended claim 1 
to include certain features of cancelled claim 2. Amended claim 1 recites "processing 
relationship value from a Financial Services Organization (FSO) transaction related data in the 
FSO computer system". Applicant respectfully requests removal of this objection. 

C. The Claims Are Not Indefinite Pursuant to 35 U.S.C. § 112. Second Paragraph 

The Examiner rejected claims 19, 42, 69, and 488 as being indefinite under 35 U.S.C. § 
112, second paragraph. AppUcant has amended claims 19, 42, 69, and 488 for clarification. 
Applicant requests removal of the rejections under 35 U.S.C. § 1 12, second paragraph. 

D. The Claims Are Not Anticipated By Sziklai Under 35 U.S.C. $102(b) 

Claims 1-74, 147, and 488 were rejected under 35 U.S.C. §103(a) as being obvious over 
U.S. Patent No. 6,341,287 to Sziklai et al. (hereinafter referred to as "Sziklai"). Applicant 
respectfully disagrees with these rejections. 
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The standard for "anticipation" is one of fairly strict identity. To anticipate a claim of a 
patent, a single prior source must contain all the claimed essential elements. Hybritech, Inc. v. 
Monoclonal Antibodies, Inc., 802 F.2d 1367, 231 U.S.P.Q.81, 91 (Fed. Cir. 1986); In re 
Donahue, 766 F.2d 531, 226 U.S.P.Q. 619, 621 (Fed. Cir. 1985). 

Claims 1, 24, and 51 have been amended to include certain features of claims 2, 25, and 
52, respectively. Amended claims 1, 24, and 51 describe combinations of features including, but 
not limited to: "wherein at least two of the processing relationship definitions stored in the 
database are configured for use in preparing a processing relationship value fi*om a Financial 
Service Organization (FSO) transaction-related data in the FSO computer system." Support for 
the amendments to claims 1, 24, and 51 may be found in claims 2, 25, and 52 and on page 54, 
lines 1-12 of Applicant's specification, which state: 

As used herein, a Financial Service Organization (FSO) is a business organization 
that provides financial services to customers and client organizations. As used 
herein, the term customer generally refers to an individual, and client organization 
generally refers to other businesses, including retail businesses and other FSOs. 
Services provided to customers and client organizations include credit products, 
such as loans and credit cards. An FSO may also provide services to client 
organizations such as credit card transaction processing. Examples of FSOs 
include, but are not limited to, banks, credit unions, insurance companies, mutual 
fimd companies, credit card companies and brokerage houses. An FSO that issues 
credit cards and processes credit card transactions may be referred to as a credit 
card institution. An FSO may include one or more organizational units. 
Examples of organizational units include, but are not limited to, main offices, , 
divisions, regional offices, and branch offices. 

Sziklai does not appear to teach or suggest at least the above-quoted features of claims 1, 24, and 
51, in combination with the other features of the claims. 

Sziklai states: 
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The report trigger table 56 records the triggers specified for reports in the 
system. The workhst item table 57 provides definitions of, and links to, modules 
launched from the worklist. The worklist table 58 provides the definitions and 
logic for worklists that facilitate work flow for a business activity. The calculation 
profile table 59 provides the definitions and logic to perform calculations related 
to data entry forms, for decision making and data input. The calculation profile 
value table 60 records the calculation profile variable values. 
(Sziklai, column 13, lines 23-32) 

Sziklai further states: 

With reference to FIG. 3, the constraint column table 81 provides 
individual data elements for the business rules. The constraint table 82 provides 
the business rules defined at the database level for every table in the application 
system, together with the meaning of each rule. The column table 72 is 
characterized in the preceding. The column allowable value table 83 provides the 
business rules at a data element level. The autofill table 84 records the automatic 
data transfer setup. The arc column table 85 provides data elements that are part of 
every usually exclusive relationship in the system. The arc table 86 records the 
mutually exclusive relationships in the system. The lookup table 87 provides the 
lookup definitions for every child table in the system. The tablename table 69 is 
characterized in the preceding. The object table 88 holds the names of the 
database objects defined in the system. The about table 89 stores versions of, and 
copyright information concerning, the system. The datatype table 90 provides the 
datatype definitions throughout the system. The dependency tree table 91 provides 
the application and database hierarchy(ies). The color table 92 provides the color 
definitions for use in various tools. 
(Sziklai, column 13, line 58 to column 14, line 12) 

Sziklai appears to teach tables that provide definitions and logic for worklists. Sziklai also 
appears to provide tables that define business rules and data elements for the rules. Sziklai does 
not appear to teach or suggest processing relationship definitions stored in a database that are 
configured for use in preparing a processing relationship value fi*om a Financial Service 
Organization (FSO) transaction-related data in an FSO computer system, in combination with the 
other features of claims 1, 24, and 51. 

Applicant submits that, for at least the reasons discussed above, claims 1, 24, and 51 and 
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the claims depending thereon are patentable over the cited art. Applicant therefore respectfully 
requests removal of the 35 U.S.C. § 102(b) rejections of these claims. 

Applicant submits that many of claims dependent on claims 1, 24, and 51 are 
independently patentable. For example, claim 3 recites: "wherein the processing relationship 
value is configured for use in identifying an FSO business entity as an owner of the FSO 
transaction-related data." Sziklai does not appear to teach or suggest at least these features of 
claim 3, in combination with the other features of the claim. 

The portions of Sziklai cited in the Office Action for the above-quoted feature of claim 3 

state: 

C. About Change Agent System describes the regulatory change system version 
information. 

The system provides a "business application browser" that combines Web 
browser technology with a selected set of business application items that are 
common to the tasks to be performed to implement information management for a 
given business area or requirement, including common functions such as 
work/task management, data entry, reporting, data processing and analysis, data 
presentation (printing, electronic display, distribution, etc.), and report and 
document preparation. 
(Sziklai, column 22, lines 10-20) 

Sziklai appears to teach a business application browser that combines web browser technology 
with items conmion to tasks to be performed to implant information management for a given 
business area. Sziklai does not appear to teach or suggest configuring a processing relationship 
value for use in identifying an FSO business entity as an owner of FSO transaction-related data. 

Claim 8 recites: "wherein the preparing the processing relationship definition comprises 
creating a highest level processing relationship object in a processing relationship structure, 
wherein the highest level processing relationship object represents an FSO." Sziklai does not 
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appear to teach or suggest at least this feature of claim 8, in combination with the other features 
of the claim. 



The portions of Sziklai cited in the Office Action for the above-quoted feature of claim 8 

state: 

The View Business Area table 36 records information about business area 
Views in the system. The Business Area table 37 holds the definition of business 
areas and forms a high level grouping of various business functions that can be 
implemented using the system. The business process business area table 38 
records information about business area processes in the system. The business 
area worklist table 39 records worklists for the business area. The View parameter 
table 40 holds the parameters that define all views in the system. 
(Sziklai, column 22, line 34 to column 23, line 36) 

Sziklai appears to teach a "Business Area" table that hold definitions of business areas and forms 
a high level grouping of various business fiinctions. Sziklai does not appear to teach or suggest 
preparing the processing relationship definition comprising creating a highest level processing 
relationship object in a processing relationship structure, the highest level processing relationship 
object representing a financial service organization. 

Claim 11 recites: "wherein the displaying one or more processing relationship object 
representations on a display screen comprises displaying values associated with a sequence 
number and a level number." Sziklai does not appear to teach or suggest at least this feature of 
claim 1 1, in combination with the other features of the claim. 

The portions of Sziklai cited in the Office Action for the above-quoted feature of claim 
1 1 state: 

The arc table 86 records the mutually exclusive relationships in the 
system. The lookup table 87 provides the lookup definitions for every child table 
in the system. The tablename table 69 is characterized in the preceding. The object 
table 88 holds the names of the database objects defined in the system. The about 
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table 89 stores versions of, and copyright information concerning, the system. The 
datatype table 90 provides the datatype definitions throughout the system. The 
dependency tree table 91 provides the application and database hierarchy(ies). The 
color table 92 provides the color definitions for use in various tools. 
(Sziklai, column 14, lines 1-12) 

FIG. 5 of Sziklai depicts relationships between several "metadata" tables. Sziklai appears to 
disclose tables that hold definitions, relationships, names, versions of the system, copyright 
information, and application and database hierarchy. Sziklai does not appear to teach or suggest 
wherein displaying processing relationship object representations on a display screen comprise 
displaying values associated with a sequence number and a level number. 

Amended claim 20 recites: "wherein the processing relationship object representations 
comprises a class of objects representing an FSO company or an FSO business unit or a bank 
branch office or a regional bank or a credit card line or an issuer or an acquirer." Sziklai does not 
appear to teach or suggest at least this feature of claim 20, in combination with the other features 
of the claim. 



The portions of Sziklai cited in the Office Action for the above-quoted feature of claim 
20 state: 

In a similar manner, reports and other output documents exist only in the 
metadata created through the Java data management layer. These output 
documents are produced by interpreting the metadata and by extracting data from 
the particular business content chosen. Events may be set up based on one or more 
changes in the business content data, but processing of an event depends on 
metadata that defines the event. Processing steps can be created to summarize and 
"filter" data, depending upon the metadata defining the summarization and 
filtering techniques. Data can be imported fi"om, and exported to, other systems 
based on metadata definitions of data structures. 
(Sziklai, column 15, lines 21-32) 



21 



Bobbitt, et al. 
09/699,015 



Assume that a data entry form is to be created based on the Department 
Table of the invention. FIG. 6 is a flow chart showing the steps used to 
accomplish this. In step 101, the Form Builder function is launched from the 
Tools Menu. In step 103, the form is given a name, and the Department Table is 
selected as the base table. In step 105, one or more fields are chosen for 
incorporation in the data entry form, and the form is uploaded to the network. A 
maximum of three steps is required to create a data entry form using the invention. 
The data entry form and its definition may be assumed to be bug-free, because the 
underlying Form Builder has been thoroughly tested and confirmed to generate the 
correct metadata definition of the desired form. 
(Sziklai, column 16, lines 22-34) 

Sziklai appears to teach documents produced by interpreting metadata and extracting data from a 
particular business content. Sziklai further appears to teach a data entry form based on a 
"Department Table". Sziklai does not appear to teach or suggest processing relationship object 
representations comprising a class of objects representing an FSO company, an FSO business 
unit, a bank branch office, or a regional bank, a credit card line, a credit card issuer, or credit card 
acquirer. 

Amended claim 147 describes a combination of features including, but not limited to: 
"wherein the one or more processing parameter values define an FSO entity in an FSO 
processing relationship tree structure stored in the database, wherein the FSO business entity is 
an FSO company or an FSO business unit or a bank branch office or a regional bank or a credit 
card line or an issuer or an acquirer". Sziklai does not appear to teach or suggest at least the 
above-quoted feature of claim 147, in combination with the other features of the claim. 

Sziklai states: 

The business content layer includes business knowledge, logical designs, 
physical designs, physical structures, relationships, and data associated with a 
selected area of business activity. A business area can be a functional field within 
an organization, such as finance or human resources, or a particular type of 
business, such as printing or a (specialty) food business, for which business- 
related data must be accumulated and managed. The business content layer is 
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defined by and referenced in the metadata layer so that the necessary objects, 
tables, columns, relationships, functions, procedures and data can be read and 
updated by the Java data management layer. The business content layer may be 
characterized as a business content database. 
(Sziklai, column 12, lines 9-21) 

Sziklai appears to teach a business content layer that includes business knowledge, logical 
designs, physical designs, physical structures, relationships, and data associated with a selected 
area of business activity. Sziklai does not appear to teach or suggest processing parameter values 
that define an FSO entity in an FSO processing relationship tree structure stored in the database, 
wherein the FSO business entity is an FSO company, an FSO business unit, a bank branch office, 
a regional bank, a credit card line, a credit card issuer, or a credit card acquirer. 



Claim 488 describes a combination of features including, but not limited to: 

wherein the computer system is configured to: 

receive a first FSO transaction-related data, 

read the selected plurality of field identifiers fi-om the first memory in 
response to the computer system receiving the first FSO transaction-related data, 

access and read a first processing parameter fi-om the second memory 
using FSO transaction-related data contained in fields of the first FSO transaction- 
related data that are identified by the selected plurality of field identifiers read 
fi-om the first memory, and 

process the first FSO transaction-related data and the first processing 
parameter. 

Sziklai does not appear to teach or suggest at least the above-quoted feature of claim 488, in 
combination with the other features of the claim. 



The Office Action states: 

As per claim 488, Sziklai teaches: A method of configuring a computer system for 
receiving and processing Financial Service Organization (FSO) transaction-related 
data, wherein each FSO transaction-related data is defined by a plurality of fields, 
each of which contains the FSO transaction-related data, the method comprising: 
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displaying a plurality of field identifiers on a display screen of a monitor, wherein 
the monitor is in data communication with the computer system, a first memory, 
and a second memory, wherein each of the displayed field identifiers identifies a 
respective field in each of the FSO transaction-related data; selecting a plurality of 
the displayed field identifiers; storing the selected plurality of field identifiers in 
the first memory; wherein the computer system is configured to receive a first 
FSO transaction-related data, wherein the computer system is configured to read 
the selected plurality of field identifiers fi"om the first memory in response to the 
computer system receiving the first FSO transaction-related data, wherein the 
computer system is configured to access and read a first processing parameter 
fi-om the second memory using FSO transaction-related data contained in fields of 
the first FSO transaction-related data that are identified by the selected plurality of 
field identifiers read fi*om the first memory, and wherein the computer system is 
configured to process the first FSO transaction-related data and the first 
processing parameter (col. 20, lines 38-43, col. 21, lines 4-23, col. 29, lines 43-56 
and lines 65-67, and col. 30, lines 1-16 and lines 44-65). 

Because the above-quoted portion of the Office Action merely recites all of the features of claim 
488, then lists a string of citations firom Sziklai, Applicant is unable to determine which portions 
of Sziklai the Examiner believes teach or suggest each of the many features of claim 488. 
Applicant respectfully requests that the Examiner specifically point out how the teachings in 
Sziklai support the rejection of the features of claim 488, or that the Examiner remove the 
rejection. 



E. Summary 

Based on the above, Applicant submits that the claims are now in condition for 
allowance. Favorable reconsideration is respectfully solicited. 

If any extension of time is required, Applicant hereby requests the appropriate extension 
of time. Should any fees be required, or if any fees have been overpaid, the Commissioner is 
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authorized to appropriately charge or credit those fees to Meyertons, Hood, Kivlin, Kowert & 
Goetzel Deposit Account No. 50-1505/5053-30802/EBM. 




Reg. No. 34,876 
Attorney for Applicant 



MEYERTONS, HOOD, KIVLIN, KOWERT & GOETZEL, P.O. 

P.O. BOX 398 

AUSTIN, TX 78767-0398 

(512) 853-8800 (voice) 

(512) 853-8801 (facsimile) 

Date: ylA-f^^ 
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